Currently, during search for website data, a user selects an element from a plurality of drop-down options displayed on a webpage, and clicks a “submit” button to send a data search request including an option element to a search server. FIG. 1 shows an instance of a webpage 100 including at least two drop-down menus for submitting a webpage request for website data. In the instance, two drop-down menus include: a region (Northern China, Eastern China, Southern China) and a year (2011, 2012, 2013), where each drop-down menu has three options. Here, elements selected by a user are Northern China and 2013.
After receiving, from a user terminal, a data search request including a selected element, a server searches an application database for application data corresponding to Northern China 2013, and sends the application data to the user terminal. The application data in this instance is, for example, recorded data of each region in a corresponding year.
Backend data is stored in an application database, and a search server usually has a caching function. To increase a search speed, the search server puts relevant application data in a cache after receiving a data search request for the first time. In this manner, when a subsequent search request is received, needed application data can be directly retrieved from the cache and fed back to a user terminal. There are mainly two existing caching manners as follows, which are described below separately.
Manner 1:
In the manner, only application data requested by a user is stored in a cache. Such a manner has an advantage that a small amount of data is cached while has a disadvantage that the probability that the cache is used is low, and it is only when same data is requested again that the cache is used. By using the case in FIG. 1 as an example, the user requests application data of Northern China 2013, and only application data about Northern China 2013 is saved in a cache. In this case, the cache takes effect only when data of Northern China 2013 is requested again, and therefore the manner cannot effectively increase a search speed.
Manner 2:
When a user requests data, a search server acquires the data requested by the user and all data relevant to the user's request and stores them in a cache. Such a manner has an advantage that the probability that the cache is used is significantly increased. By using the case in FIG. 1 as an example, the user requests application data of Northern China 2013, so that the search server acquires 9 combinations of data elements in total, that is, Northern China 2013+Northern China 2012+Northern China 2011+Eastern China 2013+Eastern China 2012+Eastern China 2011+Southern China 2013+Southern China 2012+Southern China 2011, and stores the data in a cache. In this case, when the user requests any data next time, the data can be directly retrieved from the cache. However, a disadvantage is that a huge amount of data is cached; in practical applications, it is usually unlikely that a user searches for every combination of data elements, and in most cases only uses one or two combinations, and therefore a big resource waste occurs as the rest unused data is put in the cache. By taking the case in FIG. 1 as an example, the user needs to acquire financial data of each region in the year 2013; after the first time of data search, two more combinations of data are to be used, that is, data of Eastern China 2013 and data of Southern China 2013, and therefore, caching of rest data causes a waste of a storage resource.
In conclusion, in Manner 1, a usage rate of the cache is not high, whereas in Manner 2, a usage rate of the cache is high, but a usage rate of data is low and a resource waste is big. A compromise made between Solution 1 and Solution 2 would further meet demands by increasing a usage rate of a cache while saving a resource. However, at present this kind of technology still does not exist.